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Summary 


Problem.  During  combat,  documentation  of  medical  treatment  information  is  critical  for 
maintaining  continuity  of  patient  care.  However,  knowledge  of  the  prior  status  and 
treatment  of  patients  is  limited  to  the  information  noted  on  a  paper  field  medical  card. 
The  Multi-technology  Automated  Reader  Card  (MARC)  has  been  identified  as  a 
potential  storage  mechanism  for  casualty  medical  information.  The  data  capture  and 
storage  technology  on  the  MARC  consists  of  an  integrated  circuit  computer  chip.  Since 
the  available  space  on  the  computer  chip  is  limited,  the  space  required  for  medical 
documentation  needs  to  be  determined. 

Objective.  Currently,  the  MEDTAG,  an  electronic  hand-held  field  medical 
documentation  device,  is  designed  to  write  the  individual’s  medical  data  to  the  MARC 
where  it  is  stored.  The  MARC’s  capacity  is  limited,  and  various  requirements  are 
competing  for  the  available  space.  For  example,  MARC  may  be  used  to  store  an 
individual’s  food  service,  pay,  or  personnel  data.  Therefore,  accurate  estimates  of  the 
space  needed  to  store  medical  information  collected  in  the  field  are  required.  The 
development  of  a  computer  model  that  can  be  used  to  estimate  storage  space  for  medical 
care  documentation  on  the  MARC  is  the  focus  of  this  effort. 

Approach.  MARC  ES,  a  Windows™  program  for  estimating  storage  requirements  for 
the  MARC,  was  designed  and  developed  by  the  Naval  Health  Research  Center  (NHRC). 
The  program  calculates  storage  requirements  for  a  variety  of  scenarios  using  medical 
documentation  requirements,  casualty  rates,  and  casualty  flows.  Input  parameters  to  the 
model  include  patient  condition,  upload  site,  theater,  chip  size,  and  echelon.  Using  these 
factors,  together  with  historical  data  about  field  medical  documentation  requirements  and 
patient  stream,  the  model  projects  the  storage  requirements  for  a  deployable  field  medical 
device. 

Results.  The  program  estimates  the  amount  of  space  required  to  store  medical  care 
documentation  at  forward  echelons  for  a  variety  of  patient  conditions.  The  percentage  of 
casualties  whose  medical  data  can  be  recorded  and  stored  also  can  be  calculated.  A 
variety  of  reporting  formats  are  available  for  producing  hard-copy  results  and  tables 


generated  by  the  MARC  ES  model.  A  sample  scenario  was  developed  to  illustrate  the 
capability  of  the  program. 

Discussion.  This  model  provides  a  tool  that  allows  the  user  to  detemoine  the  total 
amount  of  space  required  to  store  medical  data  at  each  echelon  of  care  for  selected 
operational  theaters.  This  information  can  be  used  to  specify  storage  space  required  to 
retain  medical  information  on  the  MARC  or  to  identify  the  point  at  which  the  data  must 
be  uploaded  from  the  MARC  if  size  constraints  are  imposed.  In  addition,  this  model  can 
be  readily  extended  to  other  systems  that  store  or  transmit  medical  data. 
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During  combat  the  handling  of  medical  information  is  a  critical  aspect  of  the 
continuity  of  casualty  care.  Medical  personnel,  however,  generally  have  limited 
knowledge  of  the  prior  status  of  their  patients  other  than  what  may  have  been  noted  on  a 
paper  field  medical  card,  which  has  many  deficiencies  (Wilcox  &  Pugh,  1990).  In 
addition,  transcribing  the  information  at  Battalion  Aid  Stations  (BASs),  Surgical  Support 
Companies,  and  other  medical  treatment  facilities  (MTFs),  can  introduce  errors. 
Historically,  the  Field  Medical  Card  (FMC,  DD1380)  has  been  used  to  provide  the 
clinical  record  that  moves  with  the  casualty  during  evacuation.  Recently,  a  hand-held, 
portable,  electronic  device,  called  MEDTAG,  has  been  shown  to  be  a  feasible  method  for 
documenting  the  required  information  at  the  forward  echelons  of  care.  It  takes  less  time 
and  provides  more  accurate  data  than  the  current  manual  method  (Galameau  &  Wilcox, 
1993a;  Galameau  &  Wilcox,  1993b;  Wilcox,  Galameau,  &  Fitzgerald,  1993). 

In  view  of  the  potential  of  the  MEDTAG  prototype,  the  Office  of  the  Secretary  of 
Defense  (Health  Affairs)  has  integrated  it  into  the  Theater  Medical  Information  System 
(TMIS;  SRA  Corporation,  1995).  An  essential  part  of  the  MEDTAG  concept  is  that 
every  military  person  carries  his  or  her  own  medical  data  on  electronic  media.  Currently, 
the  MEDTAG  is  designed  to  use  the  Multi-technology  Automated  Reader  Card  (MARC) 
to  store  the  individual’s  medical  data.  TMIS  is  exploring  the  use  of  an  individually 
carried  media  for  medical  data.  The  MARC  is  one  of  many  that  are  being  examined  as  a 
field  data  carrier  to  communicate  medical  information  between  MTFs.  The  MARC  and 
the  MEDTAG  have  the  capability  of  recording  specified  treatment  information,  such  as 
the  type  of  injury,  treatments,  and  the  type  and  time  of  administered  medications,  in 
battlefield  situations.  Further,  the  MEDTAG  software  is  capable  of  documenting  a  very 
high  percentage  of  all  relevant  information  needed  at  the  forward  echelons  of  care 
(Wilcox,  Emens,  &  Fitzgerald,  1994). 

The  MARC  is  a  “smart  card”  that  incorporates  five  different  data  storage  media: 
printed,  embossed,  bar  code,  magnetic  strip,  and  an  integrated  circuit  (IC)  chip.  The 
printing,  embossing,  and  bar  coding  on  the  card  are  static  media  -  once  they  are 
imprinted,  they  may  not  be  changed  without  reissuing  a  new  card.  By  contrast,  the 
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magnetic  strip  and  IC  chip  on  the  MARC  are  revisable  media  whose  primary  function  is 
to  store  data  that  may  change  frequently. 

The  MARC’s  IC  chip  serves  as  a  medical  data  carrier,  making  the  MARC  a 
portable  patient  record.  The  information  on  the  chip  is  divided  into  two  separate  files:  a 
demographic  record  and  a  medical  record.  All  of  the  demographic  information  can  be 
pre-encoded  on  the  MARC.  The  medical  record  section  of  the  MARC  can  include 
treatment,  medication  administered,  and  injury  description.  The  medical  record  holds 
casualty  data  encoded  by  Navy  Hospital  corpsmen.  Army  medics,  and  other  medical 
professionals. 

MARC,  used  with  the  MEDTAG,  offers  improvements  in  speed,  documentation 
quality,  and  user  satisfaction.  Although  these  improvements  in  data  collection  are 
significant,  the  greatest  benefits  of  automating  field  medical  documentation  accrue  to 
users  retrieving  data,  not  entering  them.  Medical  data  stored  electronically  are  easier  to 
read,  copy,  aggregate,  sort,  analyze,  and  transmit  than  are  data  on  paper  records.  As  a 
result,  electronic  data  can  facilitate  the  delivery  of  timely,  accurate  information  to  all  who 
need  it.  Finally,  as  an  automated  data  carrier,  MARC  offers  many  benefits  that  the  FMC 
does  not.  The  MARC  eliminates  redundant  data  entry,  improves  documentation  speed, 
facilitates  data  transferability,  and  is  more  durable.  Furthermore,  medical  personnel 
responded  favorably  to  the  MARC  and  would  rather  use  it  than  the  paper  version  in  the 
field  (R&DSD,  1994). 


Problem 

The  storage  capacity  of  the  IC  chip  on  the  MARC  is  limited,  and  there  eue 
competing  requirements  for  the  available  space.  For  example,  MARC  has  been  used  for 
manifesting  during  deployments,  for  Composite  Health  Care  System  (CHCS)  patient 
reception,  and  for  accountability  information,  such  as  personnel  location  and  status 
tracking.  It  also  can  be  used  to  store  an  individual’s  food  service,  pay,  physical  readiness 
test,  personnel,  or  legal  data.  Information  on  the  chip  may  be  shared  by  more  than  one 
application  or  function.  For  example,  demographic  information  may  be  useful  for 
medical,  personnel,  and  manifesting,  yet  only  need  be  recorded  once  on  the  chip,  thus 
eliminating  redundant  data  entry.  The  MARC’s  security  also  does  not  allow  one 
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functional  area  to  access  another’s  data;  medical  personnel  will  only  be  able  to  access 
medical  data. 

Since  the  MEDTAG  and  the  MARC  have  shown  potential  to  provide  faster,  more 
accurate  field  medical  data,  it  becomes  important  to  know  the  storage  requirements  for 
the  full  range  of  medical  problems,  treatments,  and  patient  conditions  that  could  be 
encountered  on  the  battlefield.  Currently,  allocation  for  medical  data  is  only  200  bytes  of 
the  2  KB  chip.  Therefore,  an  accurate  estimate  of  the  space  needed  to  store  medical 
information  collected  in  the  field  is  required. 

Objective 

If  the  MARC  is  to  be  dedicated  only  partially  to  the  storage  of  medical  data,  more 
study  is  needed  to  determine  the  full  extent  of  medical  data  storage  requirements.  The 
development  of  a  computer  model  that  can  be  used  to  estimate  storage  space  for  medical 
care  documentation  on  the  MARC  is  the  focus  of  this  effort.  This  report  describes  the 
model  and  computer  program  that  can  be  used  to  estimate  MARC  medical  documentation 
storage  requirements.  The  program  estimates  the  size  chip  needed  at  forward  echelons  to 
record  and  store  medical  care  documentation.  The  percentage  of  casualties  whose 
medical  data  can  be  recorded  and  stored  for  any  size  chip  is  also  calculated. 

Approach 

About  the  Model 

MARC  ES  is  a  computer  model  designed  to  estimate  MARC  storage  requirements 
for  a  variety  of  scenarios.  Figure  1  presents  a  top-level  description  of  the  MARC  storage 
model.  This  diagram  shows  the  major  data  of  the  program.  The  input  parameters,  in 
italics,  represent  factors  the  user  can  manipulate.  The  data  files,  shown  in  rectangular 
boxes,  contain  historical  information  the  program  uses.  Finally,  the  circles  represent  the 
major  tasks  the  program  performs.  The  model  works  on  and  generates  reports  from 
scenarios  developed  by  the  user. 
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Figure  1.  MARC  Storage  Model 
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iTspr  Porawiptors  Parameters  allow  the  MARC  ES  program  to  compute  multiple 
solutions  based  on  the  input  factors  selected.  The  parameters  are  described  as  follows. 

Class.  Class  refers  to  the  following  five  categories:  wounded  in  action  (WIA), 
non-battle  injury  (NBI),  disease  (D),  battle  fatigue  (BF),  and  female  specific  (FS).  Each 
patient  condition  is  classified  according  to  these  categories.  These  classes  are  not  unique, 
hence  patient  conditions  may  be  classified  into  several  classes. 

Echelon.  Echelon  refers  to  the  medical  care  and  treatment  echelons  for  which 
documentation  requirements  are  determined.  In  this  study,  Echelons  lA  (battlefield),  IB 
(Battalion  Aid  Station)  and  2  (Surgical  Support  Company)  are  the  primary  focus. 
However,  capability  is  built  in  to  address  Echelons  3  through  5  as  well. 
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Theater.  This  refers  to  the  theater  of  operations  for  which  data  are  provided.  The 
program  currently  covers  Major  Regional  Conflict  East  (MRCE)  and  Major  Regional 
Conflict  West  (MRCW).  Additional  theaters  may  be  added. 

Patient  Condition.  Using  the  Deployable  Medical  System  (DEPMEDS)  database, 
we  identified  350  distinct  patient  conditions  considered  representative  of  disorders 
expected  in  an  operational  theater  (Defense  Medical  Standardization  Board,  1994). 

Upload  Site.  The  upload  site  is  the  echelon  where  patient  data  are  uploaded  from 
their  MARC  device  to  higher-order  storage  systems  such  as  CHCS.  Since  the  MARC  has 
limited  capacity,  uploading  can  free  the  card  for  continued  use  at  the  emergency 
treatment  facility.  Medical  data  uploading  sites  are  at  the  end  of  care  at  Echelons  1  A,  IB, 
and  2. 

Chip  Size.  The  MARC  chip  may  be  manufactured  with  different  storage 
capacities.  Chip  size  refers  to  the  overall  storage  capacity  available  for  carrying  patient 
demographics,  special  conditions,  and  medical  history.  Size  is  specified  in  bytes.  The 
user  can  select  or  add  any  size  chip  according  to  the  types  of  chips  available  on  the 
market  and  how  much  storage  is  allocated  on  the  chips  for  medical  history. 

Data  Files.  The  following  data  files  are  used  in  the  cedculations  by  the  model. 
The  tables  are  all  dBASE  compatible,  which  makes  them  readily  accessible  to  many 
conunonly  available  PC  tools,  such  as  database  desktops,  spreadsheets,  and  report 
generators. 

Rates.  This  table  lists  the  rates  of  occurrence  of  injuries  per  patient  condition  for 
all  theaters  and  injury  classes.  The  rates  are  for  all  patients  who  arrive  for  treatment  by  a 
corpsman  (Echelon  lA).  Units  are  number  per  thousand  troops  per  day.  The  data  files 
contain  the  patient  condition  rates  for  two  theaters:  MRCE  and  MRCW. 

Flow.  This  table  lists  the  arrival  and  departure  rates  per  patient  condition  by 
echelon.  The  patient  flow  covers  the  five  echelons  of  care.  This  data  file  also  contains 
return  to  duty  (RTD)  rates  for  each  patient  condition  and  for  all  levels  of  care.  If 
personnel  return  to  duty,  their  medical  data  do  not  remain  on  the  card. 

Cases.  This  table  lists  the  documentation  requirements  per  patient  condition,  by 
echelon.  Subject  matter  experts  developed  medical  documentation  requirements  for  the 
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350  patient  conditions  at  Echelons  lA,  IB,  and  2.  Medical  documentation  for  each 
patient  condition  consisted  of  assessment,  treatment,  patient  conditions,  and  disposition 
appropriate  for  that  level  of  care.  Each  medical  item  recorded  in  the  patient’s  medical  file 
consisted  of  the  coded  numbers  currently  employed  in  the  MEDTAG  and  MEDTAB 
devices.  The  MEDTAB  was  developed  by  the  Naval  Health  Research  Center  to  record 
treatment  rendered  at  the  Battalion  Aid  Station  and  the  Surgical  Support  Company. 
Results  Tables.  The  user  may  select  from  the  following  list  of  tasks.  The  program 
produces  a  table  that  displays  the  result  for  the  selected  task.  Appendix  A  contains 
descriptions  of  the  data  tables. 

Rate  by  Theater.  This  table  lists  the  rates  of  occurrence  for  each  patient  condition, 
by  theater,  echelon,  and  injury  class.  The  original  source  table.  Rates,  is  filtered  by 
selecting  records  matching  the  user-specified  theater,  class,  and  echelon  parameters.  The 
rates  are  combined  with  arrival  rates  from  the  Flow  table  to  get  the  effective  rates  for 
each  echelon. 

Storage  by  Echelon.  This  table  lists  the  storage  requirements  in  bytes  per  patient 
condition  for  each  echelon.  The  number  of  documentation  elements  for  each  patient 
condition,  multiplied  by  the  data  element  size,  combined  with  the  overhead  required  to 
store  an  encounter,  gives  the  total  number  of  bytes  of  storage.  The  storage  requirements 
are  for  the  documentation  of  one  medical  treatment  encounter  and  do  not  include  space 
needed  for  demographic  or  special  condition  information.  However,  the  storage 
requirements  do  include  the  date/time  stamp.  Further,  for  Echelon  1 A  the  space  required 
includes  the  “activation  sequence”  used  by  the  MEDTAG.  The  activation  sequence 
consists  of  prompted  menus  designed  to  elicit  the  most  critical  facts  needed  in  the  field  in 
the  most  timely  manner  possible.  The  activation  sequence  has  a  fixed  storage 
requirement  of  20  bytes. 

Cumulative  Storage.  This  table  lists  the  cumulative  storage  requirements  in  bytes 
per  patient  condition  by  echelon  and  upload  site.  The  cumulative  storage  is  the  sum  of 
the  storage  required  for  one  encounter  at  each  echelon,  up  to  and  including  the  echelon  at 
which  data  are  uploaded,  plus  an  additional  per-card  overhead.  The  overhead  required  for 
the  demographics  and  special  conditions  may  be  configured  in  the  setup  dialog.  The 
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storage  requirements  include  the  space  needed  for  demographic  and  special  condition 
information.  The  amount  of  data  that  must  be  stored  varies  according  to  the  point  where 
the  data  are  uploaded  from  the  individually  carried  device  into  the  patient’s  permanent 
medical  record. 

Storage  Distribution.  This  table  lists  the  frequency  of  occurrence  versus  storage 
distribution  (bin  size)  by  theater,  injury  class,  echelon,  and  upload  site.  The  data  fix)m  the 
Storage  and  Rates  tables  are  combined  for  all  patient  conditions  and  echelons  selected  by 
the  user.  The  patient  conditions  are  sorted  into  “bins”  according  to  their  storage  sizes. 
The  rates  for  all  patient  conditions  in  each  bin  size  are  summed  to  give  the  final  result. 
For  example,  the  rates  of  all  those  patient  conditions  that  can  be  adequately  documented 
using  200  bytes  of  storage  or  less  are  added  together.  Next,  the  rates  of  patient  conditions 
that  can  be  documented  using  200  to  250  bytes  are  summed,  followed  by  the  next  larger 
bin  size,  and  so  on. 

Encounters.  This  table  lists  the  number  of  encounters  accommodated  per  chip 
size  by  patient  condition,  echelon,  and  upload  site.  The  total  number  of  encounters 
depends  on  the  initial  overhead  plus  the  number  of  medical  data  elements  needed  to 
document  each  additional  encounter.  The  initial  overhead,  counted  only  once,  includes 
demographic  and  special  condition  information. 

Percent  Cases.  This  table  lists  the  percentage  of  patient  conditions  that  can  be 
documented  per  chip  size  by  theater,  injury  class,  echelon,  and  upload  site. 

Using  the  Program 

Installation.  The  MARC  ES  program  is  written  in  Borland  Delphi,  which  is  a 
visual  application  development  system  for  Windows.  The  essentials  required  to  install, 
backup,  and  compile  the  MARC  ES  software  are  covered  in  Appendix  B. 

Wizard.  The  MARC  ES  program  handles  a  large  amount  of  data  consisting  of 
many  tables  and  forms.  Dealing  with  this  amount  of  data  and  ensuring  consistent  results 
can  be  confusing.  The  Wizard  is  an  application  expert  running  in  an  independent  window 
on  top  of  the  MARC  ES  window.  Figure  2  shows  the  introductory  Wizard  screen.  By 
clicking  on  the  <Next>  button,  the  Wizard  guides  the  user  through  an  orderly 
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sequence  of  tasks  to  set  up  historical  data,  choose  input  parameters,  view  tables,  and 
generate  reports.  At  each  step,  the  Wizard  provides  a  brief  synopsis  of  the  current  tasks, 
opens  the  necessary  windows  on  the  MARC  ES  screen,  and  provides  a  <Help>  button  for 
further  information  about  the  current  topic.  The  Wizard  will  automatically  run  the  first 
time  the  MARC  ES  program  is  started  after  installation.  A  checkbox  on  the  Wizard 
screen  explicitly  enables  or  disables  the  Wizard  screen  on  startup.  The  Wizard  is  still 
available  any  time  from  the  Help  menu. 


Figure  2.  Introductory  Wizard  Screen 
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Select  Parameters.  Figure  3  shows  the  Select  Parameters  screen  using  Wizard. 


Figure  3.  Wizard  Screen  Used  to  Select  Model  Parameters 
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The  Select  menu  provides  commands  to  select  input  parameters  for  the  MARC  ES 
model.  The  Select  menu  consists  of  the  following  parameters:  echelon,  theater, 
patient  condition,  upload  site,  class,  and  chip  size.  The  user  also  can  identify  the 
patient  conditions,  bin  size,  and  the  other  setup  configurations  from  this  same  screen. 

The  Select  Patient  Condition  dialog,  shown  in  Figure  4,  provides  a  means  to 
select  a  set  of  injury  class  parameters  from  the  MARC  ES  model.  This  determines  the 
set  of  patient  conditions  that  will  be  selected  and  viewed  in  tables.  This  filter  allows 
the  user  to  select  injuries  from  the  five  classes:  WIA,  NBI,  D,  BF,  and  FS.  Patient 
conditions  are  selected  by  highlighting  them  in  the  available  choice  box  and  then 
clicking  on  the  hand  pointing  left  in  the  direction  of  the  selected  items’  box. 
Selections  can  be  changed  using  the  arrows  at  any  time.  Clicking  on  the  double 
arrows  (  »  or  «)  allows  the  user  to  select  all  350  patient  conditions  at  one  time. 
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Figure  4.  Set  Patient  Condition  Dialog  Box 
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The  Select  Parameters  menu  also  allows  the  user  to  set  up  or  configure  the 
documentation  size  in  bytes  for  the  data  elements.  This  screen  is  shown  in  Figure  5. 


Figure  5.  The  Setup  Screen  Used  to  Configure  Size  of  the  Data  Elements 
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The  following  data  elements  can  be  configured  from  the  Setup  menu: 

Data  Element  Size'.  The  size  of  a  medical  data  element  is  the  number  of  bytes 
required  per  medical  action  item. 

Date/Time  Stamp  Size:  A  date/time  stamp  is  included  in  the  patient  record.  The  date/ 
time  stamp  size  is  the  number  of  bytes  required  per  medical  encounter  to  record  the 
date  and  the  time. 

Demographics  Size:  The  demographics  size  is  the  number  of  bytes  required  per 
MARC  to  record  the  patient  demographic  information.  Demographic  information 
includes  name,  social  security  number,  rank,  branch,  and  religion. 

Special  Conditions  Size:  The  special  conditions  size  is  the  number  of  bytes  required 
per  MARC  for  recording  the  patient  special  conditions.  The  special  condition  section 
is  free  text  and  can  be  read  but  not  changed.  Information  in  this  section  includes 
blood  type,  allergies,  and  other  special  conditions. 

Activation  Sequence  Size:  The  activation  sequence  size  is  the  number  of  bytes 
required  per  medical  encounter  (currently  Echelon  lA  only)  for  recording  basic 
patient  condition  and  injury  information  (Wilcox  et  al.,  1993). 

If  the  user  changes  the  setup  configuration,  the  affected  tables  are  automatically 
marked  for  recalculation  so  that  the  new  values  are  incorporated.  This  applies  to  the 
Storage  by  Echelon  and  Cumulative  Storage  tables. 

The  Select  Bins  dialog  allows  the  user  to  select  a  set  of  storage  size  bin 
parameters  from  the  MARC  ES  model.  This  is  a  technique  of  dividing  a  frequency 
distribution  into  discrete  ranges  to  facilitate  analysis  and  visualization.  Data  are  placed 
into  one  of  the  defined  bins  if  the  values  fall  within  the  lowest  and  highest  ranges  of  the 
bin.  This  allows  a  distribution  chart  to  be  tailored  to  a  manageable  set  of  ranges,  instead 
of  a  potentially  large  number  of  values. 

Select  Tasks.  Tasks  or  Results  Tables  can  be  selected  using  the  toolbar  or  the 
drop-down  task  menu.  When  a  task  command  is  selected,  a  data  window  is  displayed. 
Most  tables  obtain  data  from  one  or  more  other  tables  and  display  a  computed  relation  of 
their  input  elements  and  parameters.  Changing  a  parameter  forces  the  table  to  recalculate. 
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Tables.  A  variety  of  reporting  formats  are  available  for  producing  hard-copy 
results  and  tables  generated  by  the  MARC  ES  model.  All  changes  to  the  table  are  saved 
whenever  the  user  moves  from  the  current  record.  Most  tables  have  a  <Find>  button  on 
the  toolbar.  Clicking  on  the  <Find>  button  brings  up  a  floating  Find  dialog,  which  allows 
the  user  to  search  on  any  field  of  the  table.  Typically,  this  works  best  for  patient 
conditions  since  there  are  so  many  of  those,  but  any  field  can  be  selected  from  the  drop¬ 
down  list. 

Refresh  Option.  A  subset  of  the  available  parameters  can  be  changed  from  the 
Select  menu.  Refresh  recalculates  the  data  from  one  or  more  tables  and  displays  a 
computed  relation  of  their  input  elements  and  parameters.  Any  table  is  automatically 
recalculated  when  any  of  the  data  or  parameters  on  which  it  depends  have  changed. 

Charting.  Tables  can  be  charted  automatically.  Chart  displays  the  table  in  the 
form  of  a  3D  bar  chart.  The  Chart  Options  dialog  displays  one  or  more  parameters  the 
user  can  select  to  filter  the  chart  display.  The  chart  allows  the  user  to  set  many  different 
options.  The  popup  menu  allows  various  chart  tools,  including  palette  bar,  pattern  bar, 
and  data  editor,  to  be  selected.  In  this  application  extensive  use  of  these  options  are  not 
used,  but  they  are  included.  The  user  can  click  with  the  right  mouse  button  on  a  data 
point  to  display  a  popup  bubble  showing  the  actual  data  value.  The  legend  displays  color 
and  text  information  for  the  chart. 

Printing.  The  tables  generated  by  the  program  can  be  printed  using  Quick 
Reports  or  ReportSmith.  The  user  can  generate  a  report  by  clicking  the  FilelPrint  menu 
for  the  individual  table.  This  opens  a  preview  form  showing  the  table  to  be  printed.  The 
<Print>  button  on  the  preview  form  sends  the  table  to  the  printer. 

Results 

This  section  describes  one  example  scenario  selected  to  depict  the  tables  and 
charts  generated  when  using  the  MARC  ES  program.  The  Setup  Configuration,  shown  in 
Table  1,  is  used  for  the  following  example. 
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Table  1 

Setup  Configuration  for  the  MARC  ES  Program 


Element 

Size  in  Bytes 

Data  Element 

2 

Date/Time  Stamp 

14 

Demographics 

80 

Special  Conditions 

40 

Activation  Sequence 

20 

The  size  of  the  space  required  for  an  individual  medical  data  element  is  2  bytes,  the 
date/time  stamp  requires  14  bytes,  demographics  uses  80  bytes,  and  special  conditions 
needs  40  bytes.  The  activation  sequence  used  only  for  Echelon  1 A  uses  20  bytes. 

The  Parameters  chosen  for  the  example  are  shown  in  Table  2. 

Table  2 

User  Parameters  Chosen  for  MARC  ES  Program 


Parameter 

Selection 

Patient  Conditions 

350 

Bin  Sizes 

100,  150,  200,  250,  300, 
350,  400,  450,  500 

Theater 

MRCW 

Class 

WIA,  NBI,  D,  BF,  FS 

Echelon 

lA,  IB,  2 

Upload  Site 

2 

Chip  Size  (in  bytes) 

200, 400,  800, 1200, 1600 

In  this  example,  MRCW  is  selected  as  the  theater,  the  echelons  of  interest  selected 
are  lA,  IB,  and  2,  the  upload  site  chosen  is  Echelon  2,  five  different  chip  sizes  in  bytes 
(200,  400,  800,  1200,  1600),  and  all  350  patient  conditions  are  also  selected.  These 
parameters  also  can  be  selected  from  the  Select  menu  of  the  main  program.  When  a 
parameter  is  selected,  a  conunon  dialog  box  that  accompanies  the  selection  of  each 
parameter  is  displayed. 

A  variety  of  scenarios  can  be  created  by  varying  the  parameters  selected.  For 
example,  storage  requirements  for  patient  conditions  classified  as  disease  can  be 
estimated  for  both  MRCW  and  MRCE.  Or,  patient  conditions  classified  as  multiple 
injury  wounds  (MIWs)  can  be  used  to  estimate  the  storage  required  for  documentation. 
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The  MIW  would  be  expected  to  require  the  most  treatment  and  therefore  require  the  most 
documentation  space.  The  setup  configuration  also  can  be  altered  to  reflect  any  coding 
scheme  by  changing  the  size  in  bytes  of  the  data  elements.  The  demographics  and  special 
conditions  storage  areas  also  can  be  made  larger  or  smaller  by  changing  their  size  dining 
setup. 

After  the  input  parameters  are  identified,  several  tasks  may  be  chosen.  Figure  6 
shows  the  results  produced  when  the  Rates  by  Theater  task  is  selected.  This  table 
provides  the  rate  of  occurrence  for  each  of  the  selected  patient  conditions  in  the  MRCW 
theater  arriving  at  each  echelon. 
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Figure  6.  Rates  by  Theater  Task 
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For  example.  Patient  Condition  001,  a  cerebral  concussion  classified  as  WIA,  has 
the  rate  of  occurrence  of  .01268668  at  Echelons  lA,  IB,  and  2  for  MRCW  theater. 
Patient  Condition  002,  a  cerebral  concussion  resulting  from  NBI,  has  a  rate  of  occurrence 
of  .00813  at  Echelons  lA  and  IB  and  of  .0069686  at  Echelon  2.  The  model  uses  this 
information  to  estimate  the  percentage  of  patient  conditions  that  can  be  documented  while 
chip  size,  theater,  echelon,  and  upload  site  vary.  The  user  can  print  the  table  or  display 
the  table  as  a  chart. 
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Figure  7  shows  the  results  generated  by  the  Cumulative  Storage  task.  The 
cumulative  number  of  bjdes  needed  for  documentation  for  the  selected  patient  conditions 
at  each  echelon  is  calculated.  For  example,  Patient  Condition  001  requires  164  bytes  for 
medical  documentation  at  Echelon  lA,  228  bytes  at  Echelon  IB,  and  318  bytes  at 
Echelon  2. 

Figure  7.  Cumulative  Storage  Task 
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The  164  bytes  required  for  documentation  at  Echelon  lA  includes  44  bytes  for 
medical  information  and  date/time  stamp  and  120  bytes  for  demographics  and  special 
condition  information.  At  Echelon  IB,  228  bytes  are  estimated,  the  164  bytes  from 
Echelon  lA  plus  64  for  additional  medical  information,  while  at  Echelon  2,  90  bytes  are 
estimated  for  additional  medical  information  plus  the  228  from  the  two  previous 
echelons.  Storage  by  individual  echelon  can  be  calculated  and  displayed  by  choosing  the 
Storage  by  Echelon  selection  from  the  Task  menu. 
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The  Cumulative  Storage  table  also  can  be  displayed  as  a  chart  (see  Figure  8). 
The  patient  conditions  are  displayed  along  the  x-axis  and  are  labeled  in  the  legend.  The 
storage  size  in  bytes  is  shown  on  the  y-axis.  The  user  can  click  on  the  right  mouse  button 
on  a  data  point  to  display  a  popup  bubble  showing  the  actual  data  value.  From  the  chart 
window  the  user  can  edit  titles  and  legends,  change  fonts  and  font  sizes,  and  modify  scale 
ranges. 

Figure  8.  Cumulative  Storage  Requirements 
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The  number  of  encounters  that  various  chip  sizes  can  accommodate  for  each 
patient  condition  at  Echelons  1  A,  IB,  and  2  are  shown  in  Figure  9.  The  total  number  of 
encounters  is  estimated  by  calculating  the  initial  overhead  plus  the  number  of  data 
elements  needed  to  document  each  additional  encounter.  For  example,  for  Patient 
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Condition  001  (Cerebral  Concussion)  a  400-byte  allocation  can  hold  6  different  medical 
encounters  at  Echelon  1  A,  3  encounters  at  Echelon  IB,  and  1  encounter  at  Echelon  2. 


Figure  9.  Number  of  Encounters  Documented  for  Each  Patient  Condition 
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Figure  9  also  shows  that,  at  Echelon  1  A,  a  200-byte  allocation  can  store  only  one 
medical  encounter,  while  at  Echelons  IB  and  2  a  200-byte  allocation  cannot  hold  even 
one.  It  can  be  expected  that  while  at  Echelons  IB  or  2  the  patient  is  likely  to  be  assessed 
and  treated  more  than  once. 

Figure  10  displays  the  number  of  encounters  that  the  various  amounts  of  storage 
space  allocated  can  handle  at  Echelon  lA.  The  user  can  select  chart  options  to  identify 
the  echelon  of  interest.  The  number  of  encounters  for  Echelons  IB  and  2  also  can  be 
displayed  using  the  chart  options. 
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Figure  10.  Number  of  Encounters  Documented  by  Amount  of  Storage  Space  Allocated 
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The  Percent  Cases  result  is  shown  in  Figure  11.  This  table  displays  the  percentage 
of  the  patient  conditions  that  can  be  documented  once  for  various  amounts  of  storage 
space.  This  distribution  allows  one  to  determine  the  percentage  of  cases  that  different 
capacity  chips  can  accommodate.  For  example,  for  those  patient  conditions  classified  as 
WIA,  200-bytes  of  storage  can  accommodate  99.41%  at  Echelon  lA,  3.69%  at  Echelon 
IB,  and  none  at  Echelon  2.  This  table  indicates  that  for  WIA,  NBI,  D,  BF,  and  FS  patient 
conditions  100%  of  all  cases  at  Echelons  1  A,  IB,  and  2  can  be  stored  within  an  800-byte 
space.  However,  in  this  example,  only  one  medical  encounter  is  documented  at  each 
echelon. 


19 


Figure  11.  Pecentage  of  Cases  Documented  by  Amount  of  Storage  Space  Allocated 
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Discussion  and  Conclusions 

This  model  provides  a  tool  that  allows  the  user  to  estimate  the  total  amount  of 
space  required  to  store  medical  data  at  each  echelon  of  care  for  selected  operational 
theaters.  This  information  can  be  used  to  specify  the  amount  of  storage  space  required  to 
retain  medical  information  on  the  MARC.  By  selecting  various  parameters  and 
modifying  the  setup,  a  variety  of  casualty  scenarios  can  be  created.  In  the  example 
presented  here  all  350  patient  conditions  were  selected,  the  region  of  interest  was 
MRCW,  and  the  chip  sizes  chosen  included  200,  400,  800,  1200,  and  1600  bytes.  The 
results  indicated  that  800  bytes  could  accomodate  all  of  the  demographic  data,  special 
condition  information,  and  medical  documentation  for  one  encounter  at  Echelons  lA,  IB, 
and  2. 


20 


The  MARC  ES  program,  however,  allows  the  user  to  select  any  combination  of 
input  variables.  The  setup  configuration  can  be  modified  to  allocate  storage  space  for 
demographic  information  or  to  evaluate  the  impact  of  coding  special  condition 
information  rather  than  storing  it  in  a  free-text  format.  In  addition,  the  program  can  be 
used  to  identify  the  point  at  which  data  must  be  uploaded  from  the  MARC  if  size 
constraints  are  imposed. 

The  MARC  ES  program  has  several  features  that  contribute  to  its  flexibility.  For 
example,  data  tables  can  be  imported  easily  and  new  information  can  be  added  to  the 
program  at  any  time.  The  Cases  data  file,  which  documents  the  medical  treatment 
provided  at  each  of  the  echelons,  can  be  modified  at  any  time  using  the  Import  feature. 
Changes  or  updates  in  the  injury  rates  also  can  be  made.  Additional  theaters,  patient 
conditions,  echelons  of  care,  chip  sizes,  and  upload  sites  can  all  be  appended  to  reflect  the 
latest  information. 

Currently,  this  model  is  specific  to  the  storage  of  medical  data  on  the  MARC 
because  the  Cases  file  assumes  that  the  MARC/MEDTAG  coding  scheme  is  used. 
However,  by  selecting  setup  sizes  and  bins,  the  user  can  reconfigure  the  data  element 
sizes  and  approximate  the  storage  requirements  of  any  documentation  coding  scheme. 

Further,  this  model  can  be  readily  extended  to  other  systems  that  store  or  transmit 
medical  data  in  one  of  two  ways.  First,  a  factor  representing  the  relative  efficiency  of  the 
MARC/MEDTAG  storage  system  and  the  alternative  system  could  be  estimated.  The 
model  results  then  could  be  multiplied  by  this  factor.  Second,  a  new  Cases  file  could  be 
developed  that  reflects  the  coding  used  in  the  alternative  system. 
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Glossary:  Terms  and  Abbreviations 

1.  Action  Item.  Medical  action  items  recorded  in  patient  medical  files  consist  of  coded 
numbers  as  currently  employed  in  the  MEDTAG  and  MEDTAB  devices. 

2.  Bin.  This  is  a  technique  of  dividing  a  frequency  distribution  into  discrete  ranges  to 
facilitate  analysis  and  visualization.  Data  are  placed  into  one  of  the  defined  bins  if  the 
values  fall  within  the  lowest  or  highest  ranges  of  the  bin.  This  allows  a  distribution  chart 
to  be  tailored  to  a  manageable  set  of  ranges,  instead  of  a  potentially  large  number  of 
values.  Bin  sizes  may  be  identified  by  the  user. 

3.  Chip.  The  electronic  device  in  which  each  person  carries  his  or  her  own  medical  data 
to  fulfill  the  function  of  the  field  medical  card.  The  prototype  device  is  the  MARC,  a 
smart  card  containing  a  computer  chip  that  can  store  treatment,  medicines  administered, 
and  injury  information. 

4.  Chip  Size.  This  refers  to  the  overall  storage  capacity  available  for  carrying  patient 
demographics,  special  conditions,  and  medical  history.  Size  is  specified  in  bytes,  iuid  it 
determines  the  number  of  medical  action  items  that  the  chip  can  accommodate. 

5.  Class.  This  refers  to  the  following  five  categories:  WIA,  NBI,  D,  BF,  and  FS.  Each 
patient  condition  is  classified  according  to  these  categories.  These  classes  are  not  unique, 
hence  patient  conditions  may  be  classified  in  more  than  one  class. 

6.  Echelon.  This  refers  to  the  medical  care  and  treatment  echelons  for  which 
documentation  requirements  are  determined.  In  this  study.  Echelons  lA  (battlefield),  IB 
(Battalion  Aid  Station)  and  2  (Surgical  Support  Company)  are  the  primary  focus. 
However,  capability  is  buUt  in  to  address  Echelons  1  through  5. 

7.  Patient  Condition.  Using  the  DEPMEDS  database,  350  patient  conditions  were 
identified. 

8.  Rates.  The  rates  of  occurrence  of  injuries  and  patient  conditions  are  provided.  Rates 
are  specified  in  terms  of  the  number  of  occurrences  per  1,000  troops  per  day. 

9.  Theater.  This  refers  to  the  theater  of  operations  for  which  data  are  provided.  The 
program  currently  covers  MRCE  and  MRCW.  Additional  theaters  may  be  added. 

10.  Upload  Site.  The  upload  site  is  the  echelon  in  which  patient  data  are  uploaded  from 
their  MARC  device  to  higher  levels  of  care.  Since  the  MARC  has  limited  capacity, 
uploading  can  free  the  card  for  continued  use  at  the  emergency  treatment  facility.  Medical 
data  uploading  sites  are  at  the  end  of  care  at  Echelons  1  A,  IB,  and  2. 
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Appendix  A 

Data  Tables  and  Lookup  Tables 


The  primary  data  structures  used  are  encompassed  in  the  following  tables. 

TABLE  NAME:  ECHELON 

DESCRIPTION:  Echelons  -  This  table  lists  the  (6)  echelons,  and  a  descriptive  name  for  each 
echelon.  Each  echelon  is  assigned  a  unique  “ECHELON”  code  (1  A,1B,2,3,4,5)  for  reference 
purposes. 

HELD  NAME  TYPE  SIZE  DEC 
ECHELON  C  5 

NAME  C  50 

TABLE  NAME:  PATCOND 

DESCRIPTION:  Patient  conditions  -  This  table  lists  the  (350)  patient  conditions,  a  descriptive 
name,  and  the  category  into  which  each  condition  falls.  Each  patient  condition  is  assigned  a 
unique  “PCOND”  code  (1..350)  for  reference  purposes.  The  “category”  field  is  used  to  access 
the  “category”  table  directly. 

FIELDNAME  TYPE  SIZE  DEC 
PCOND  C  5 

NAME  C  50 

CATEGORY  C  5 

TABLE  NAME:  THEATER 

DESCRIPTION:  Theaters  -  This  table  lists  the  (3)  theaters,  a  descriptive  name,  and  an 
abbreviation  for  each  theater.  Each  theater  is  assigned  a  unique  “THEATER”  code  (1..3)  for 
reference  purposes. 

FIELDNAME  TYPE  SIZE  DEC 
THEATER  C  5 

NAME  C  50 

ABBREV  C  5 

TABLE  NAME:  CLASS 

DESCRIPTION:  Injury  classes  -  This  table  lists  the  (5)  classes  defined  for  patient  conditions  and 
a  descriptive  name  for  each  class  (Wounded  in  Action,  Non  Battle  Injury,  Disease,  Female 
Specific,  Battle  Fatigue).  Each  class  is  assigned  a  unique  “CLASS”  code  (1..5)  for  reference 
purposes. 

FIELDNAME  TYPE  SIZE  DEC 
CLASS  C  5 

NAME  C  50 

TABLE  NAME:  CHIPSIZE 

DESCRIPTION:  Computer  chips  -  This  table  lists  the  available  computer  chips  and  the  size  of 
available  space  in  bytes  for  each  chip. 


FIELDNAME  TYPE 

SIZE 

DEC 

CHIP 

C 

5 

NAME 

C 

50 

SIZE 

N 

10 
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TABLE  NAME:  CATEGORY 

DESCRIPTION:  Categories  -  This  table  lists  the  (27)  categories  defined  for  patient  conditions 
and  a  descriptive  name  for  each  category.  Each  category  is  assigned  a  unique  “CATEGORY” 
code  (1..27)  for  reference  purposes. 

FIELDNAME  TYPE  SIZE  DEC 
CATEGORY  C  5 

NAME  C  50 

TABLE  NAME:  ACTION 

DESCRIPTION:  MEDTAG  action  codes  -  This  table  lists  the  medical  data  elements  and  menu 
elements  as  used  in  the  current  MEDTAG  and  MEDTAB  systems.  This  table  can  be  used  to 
determine  or  simulate  menu  selections  used  in  MEDTAB  to  document  a  patient  condition. 
“NAME”  is  a  shortened  name  for  a  data  element,  as  used  in  menus  in  MEDTAB. 
“DESCRIPTION”  is  a  complete  name  for  a  data  element,  as  used  in  reports  or  external 
documentation.  “ATTR”  is  a  code  describing  the  attributes  of  a  data  element,  as  used  in 
MEDTAB  to  document  a  patient  condition.  The  “ATTR”  field  can  be  used  to  determine  what 
additional  documentation  may  be  required,  such  as  location,  body  area,  or  quantity  of 
medication.  Each  data  element  is  assigned  a  unique  “CODE”  action  code  (1.. 32000)  for 
reference  purposes. 


FIELDNAME  TYPE 

SIZE 

DEC 

CODE 

C 

TAG 

C 

ATTR 

C 

10 

PROPS 

C 

5 

NAME 

C 
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DESCRIPTION 

C 

50 

TABLE  NAME:  RATES 

DESCRIPTION:  Rates  of  occurrence  -  This  table  lists  the  rates  of  occurrence  per  1,000  troops 
per  day.  The  table  is  triple-indexed  on  “PCOND”  (patient  condition),  “THEATER”,  and 
“CLASS”  (injury  class). 

FIELDNAME  TYPE  SIZE  DEC 
PCOND  C  5 

THEATER  C  5 

CLASS  C  5 

RATE  N  13  7 

TABLE  NAME:  FLOW 

DESCRIPTION:  Arrival  departure  flow  -  This  table  lists  the  arrival  and  departure  rates  at  each 
echelon,  for  each  patient  condition.  The  table  is  double-indexed  on  “PCOND”  (patient 
condition)  and  “ECHELON”. 

FIELDNAME  TYPE  SIZE  DEC 
PCOND  C  5 

ECHELON  C  5 

ARRIVE  N  10  0 

RTD  N  10  0 

DIE  N  10  0 
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TABLE  NAME:  CASES 

DESCRIPTION:  Documentation  requirements  for  cases  -  This  table  lists  the  documentation 
requirements  for  each  echelon,  for  each  patient  condition.  The  table  is  double-indexed  on 
“PCOND”  (patient  condition)  and  “ECHELON”.  The  table  is  a  one-to-many  relationship 
between  patient  condition  and  data  element  code.  “CODE”  is  a  code  referencing  a  MEDTAB 
data  element. 


FIELDNAME  TYPE 

SIZE 

DEC 

PCOND 

C  5 

ECHELON 

C 

5 

CODE 

C 

5 

TABLE  NAME:  ERATES 

DESCRIPTION:  Rates  by  theater  -  This  table  lists  the  rates  of  occurrence  per  1,000  troops  per 

day.  The  table  is  triple  indexed 

on  “PCOND”  (patient  condition),  “THEATER”,  and  “CLASS” 

(injury  class). 
FIELDNAME  TYPE 

SIZE 

DEC 

PCOND 

C  5 

THEATER 

C 

5 

CLASS 

C 

5 

ECHELON 

C 

5 

RATE 

N 

13  7 

TABLE  NAME:  STORAGE 

DESCRIPTION:  Storage  requirements  -  This  table  lists  the  storage  requirements  in  bytes  for 
each  patient  condition  at  each  echelon. 

FIELDNAME  TYPE 

SIZE 

DEC 

PCOND 

C  5 

ECHELON 

C 

5 

SIZE 

N 

10  0 

TABLE  NAME:  ASTORAGE 

DESCRIPTION:  Cumulative  storage  requirements  -  This  table  lists  the  cumulative  storage 
requirements  in  bytes  for  each  patient  condition  at  each  echelon,  per  upload  site. 

FIELDNAME  TYPE 

SIZE 

DEC 

PCOND 

C  5 

ECHELON 

C 

5 

UPLOAD 

C  5 

SIZE 

N 

10  0 

TABLE  NAME:  DSPACE 

DESCRIPTION:  Storage  distribution  -  This  table  lists  the  frequency  versus  storage  distribution 
per  theater,  class,  echelon,  and  upload  site. 

FIELDNAME  TYPE 

SIZE 

DEC 

THEATER 

C 

5 

CLASS 

C 

5 

ECHELON 

C 

5 

UPLOAD 

C  5 

RATE 

N 

13  7 

SPACE 

N 

10  0 
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TABLE  NAME:  PCASES 

DESCRIPTION:  Percent  cases  documented  -  This  table  lists  the  percent  cases  documented 
versus  chip  size,  per  theater,  class,  echelon,  and  upload  site. 

FIELDNAME  TYPE  SIZE  DEC 

THEATER  C  5 

CLASS  C  5 

ECHELON  C  5 

UPLOAD  C  5 

CHIP  C  5 

PERCENT  N  13  7 

TABLE  NAME:  ENCOUNT 

DESCRIPTION:  Number  of  encounters  -  This  table  lists  the  number  of  encounters 

accommodated  versus  chip  size,  per  patient  condition,  echelon,  and  upload  site. 

FIELDNAME  TYPE  SIZE  DEC 

PCOND  C  5 

ECHELON  C  5 

UPLOAD  C  5 

CHIP  C  5 

ENCOUNTER  N  10  0 
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Appendix  B 

MARC  ES  Version  1.1  for  Windows 
Installation  Instructions 

INTRODUCTION.  MARC  ES  is  a  Windows  program  for  estimating  medical  storage 
requirements  for  the  MARC.  This  file  contains  details  about  the  contents  of  the  package, 
installation  instructions,  and  help  on  getting  started  and  using  the  package. 

SYSTEM  REQUIREMENTS.  The  following  hardware  and  software  are  required  to 
install  and  run  the  MARC  ES  package  on  your  computer: 

Windows  3.1  or  later.  The  MARC  ES  has  been  tested  under  Windows  3.1  and 
Windows  NT.  It  has  not  been  fully  tested  under  Windows  ‘95  but  it  should  run  as 
well  as  it  does  under  Windows  NT. 

4.0  MB  minimiim  of  free  disk  space  is  required  to  install  the  MARC  ES  software  and 
basic  set  of  database  tables.  More  space  is  required  to  allow  for  expansion  of 
databases  and  other  applications. 

386DX/33  MHZ  or  better  processor,  486DX/66  MHZ  or  better  is  recommended.  A 
386  should  be  equipped  with  math  co-processor. 

4  MB  of  memory,  8  MB  to  16  MB  recommended,  particularly  if  running  under 
Windows  NT  or  ‘95.  The  amount  of  memory  will  greatly  affect  the  performance  of 
the  program.  If  you  have  too  little  memory,  it  will  spend  much  of  its  time  swapping  to 
disk.  Sufficient  memory  space  should  be  made  available  for  disk  caching  to  improve 
performance. 

VGA  color  display.  Super  VGA  recommended. 


Contents  of  the  Package.  The  MARC  ES  package  consists  of  three  components, 
distributed  on  several  diskettes: 


DISKETTE 

1-2 

3-4 

5-9 


DESCRIPTION 
MARC  ES  software 
Borland  Database  Engine  (BDE) 
ReportSmith  reporting  engine 


Contents  of  MARC  ES  Disk  1.  The  following  MARC  ES  files  are  on  the  distribution 
diskette.  Most  files  are  compressed  and  will  be  decompressed  onto  your  hard  drive 
during  the  install  process.  Some  files  are  used  only  during  setup  and  will  not  be  copied  to 
your  hard  drive: 

ACTION.DB_  ENCOUNT.MD_  RATES.DB_ 

ACTION.MD_  ENCOUNT.RP_  README.TXT 
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ASTORAGE.DB_ 

ASTORAGE.MD. 

BIVBX11.DL_ 

CASES.DB. 

CASES.MD_ 

CATEGORY.DB, 

CATEGORY.MD. 

CHART2FX.VB_ 

CHIPSIZE.DB_ 

CLASS.MD_ 

CTL3D.DLL 

DSPACE.DB_ 

DSPACE.MD_ 

ECHELON.DB_ 

ECHELON.MD_ 

ENCOUNT.DB_ 


ERATES.DB_ 

ERATES.MD_ 

LOW.DB_ 

FLOW.MD. 

INSTALDR.EXE 

INSTALL.INF 

MARC.EX_ 

MARC.IN_ 

ARCES.HL_ 

PATCOND.DB_ 

PATCOND.MD_ 

PCASES.DB_ 

CASES.MD_ 

CLASS.MD. 

CLASSX)B_ 

COND.DB_ 


SETBIN.DB_ 

SETCAT.DB_ 

SETCfflP.DB_ 

SETCLASS.DB_ 

SETECH.DB_ 

SETPC.DB_ 

SETSIJM.IN_ 

SETTHE.DB, 

SETUP.DB_ 

SETUP.EXE 

SETUPL.DB_ 

STORAGE.DB_ 

STORAGE.MD_ 

THEATER.DB 

THEATER.MD_ 


Contents  of  MARC  ES  Disk  2. 


IA. EX_ 

IB. EX_ 

ASTORAGE.RP_ 

DSPACE.RP_ 


CH22.DB_ 

NCOUNT.RP_ 

ERATES.RP 


PCASES.RP_ 

STORAGE.RP 

UNPAKSMP.BAT 


Contents  of  Disks  3-4.  These  diskettes  contain  the  Borland  Database  Engine  (BDE) 
component.  The  BDE  package  is  distributed  as  part  of  the  MARC  ES  software,  in  terms 
of  the  Borland  Redistributable  License  Agreement.  The  BDE  may  be  used  only  for  the 
purposes  of  running  the  MARC  ES  program. 

Contents  of  Disks  5-9.  These  diskettes  contain  the  ReportSmith  Runtime  component. 
ReportSmith  is  distributed  as  part  of  the  MARC  ES  software,  in  terms  of  the  Borland 
Redistributable  License  Agreement.  ReportSmith  may  be  used  only  for  the  purposes  of 
running  the  MARC  ES  program. 


Tnstfllling  MARC  ES.  A  full  installation  of  MARC  ES  requires  three  steps: 


1.  Install  the  MARC  ES  software 

2.  Install  the  BDE 

3.  Install  the  ReportSmith  Runtime  (OPTIONAL) 


Install  the  MARC  ES  Software.  To  install  MARC  ES,  run  the  Setup  program  from  the 
MARC  ES  diskette  under  Windows.  Setup  copies  the  files  to  your  hard  disk  and  creates 
a  program  group  under  Windows,  with  a  MARC  ES  icon,  hi  most  cases  that's  all  there  is 
to  setting  up  MARC  ES.  If  you  experience  problems  in  installing  or  running  the  software 
refer  to  the  Troubleshooting  section  at  the  end  of  this  document. 

Upgrading  From  a  Previous  Version.  If  you  are  upgrading  MARC  ES  from  a  previous 
version,  follow  the  same  basic  procedures  as  the  normal  installation.  During  Setup  you 
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will  be  presented  with  some  options  for  the  components  to  be  installed.  If  you  wish  to 
preserve  your  datafiles,  ensure  that  the  Databases  option  is  set  to  No,  otherwise  the  data 
files  will  be  overwritten  from  the  setup  disk.  Any  changes  you've  made  will  be  lost.  The 
necessary  files  to  perform  the  upgrade  will  automatically  be  copied  to  the  hard  drive. 
Newer  files  will  replace  older  files. 

Install  the  BDE.  Install  the  BDE  by  running  Setup  from  the  BDE  DISK  1  under 
Windows.  Follow  instructions  to  complete  the  installation. 

sk  Hi  sic******^:**  *******  *************  NOTE  ********************************* 
Installing  the  BDE  will  alter  some  of  your  Windows  setups!  Please  exercise  caution,  especially  if  you  are 
running  either  dBASE  or  PARADOX  on  your  system.  Since  both  those  packages  also  use  the  BDE,  it  is 
possible  that  some  files  may  be  replaced  with  an  incompatible  version  from  the  BDE  supplied  here.  The 
best  procedure  is  to  make  backups  of  all  PARADOX/dBASE  drivers  and  dynamic  link  libraries  first  before 
installing  MARC  ES.  If  in  doubt,  please  consult  your  system  administrator,  or  contact  the  supplier. 

H;*********************************************************************** 


Install  the  ReportSmith  (OPTIONAL).  To  install  ReportSmith,  run  the  Install  program 
from  the  first  ReportSmith  diskette  under  Windows.  You  will  be  prompted  to  insert  each 
of  the  5  diskettes  required  to  install  the  ReportSmith  Runtime  support.  ReportSmith  is  a 
very  flexible  and  powerful  tool  for  generating  and  printing  reports.  It  can  be  used  to 
modify  reports,  or  even  to  produce  completely  new  reports.  Existing  reports  are  viewed 
and  printed  with  the  ReportSmith  Runtime,  which  is  shipped  with  MARC  ES.  If  you  wish 
to  modify  or  extend  the  reports,  the  full  release  of  ReportSmith  is  required. 

*****************  NOTE;  REPORTSMITH  IS  OPTIONAL  ******************** 
ReportSmith  is  needed  only  if  you  wish  to  print  reports.  Otherwise  it  will  not  be  required.  The  ReportSmith 
window  is  activated  from  the  Print  menu  or  <Print>  button  in  several  data  windows.  If  you  click  on  a  Print 
icon,  and  ReportSmith  is  not  installed,  you  will  receive  an  error  notification  message.  The  ReportSmith 
Runtime  can  print  any  of  the  preconfigured  reports  shipped  with  MARC  ES.  If  you  wish  to  design  your  own 
reports,  or  modify  any  of  the  existing  reports,  the  full  version  of  ReportSmith,  or  another  application, 
capable  of  producing  compatible  report  formats,  will  be  required. 

HcHJ********5i:H:*  *************************************************  ********** 


Help  on  Using  MARC  ES.  To  run  the  MARC  ES  program,  go  to  Windows  Program 
Manager,  open  the  MARC  ES  group,  and  click  on  the  MARC  icon.  Or  Run  MARC.EXE 
from  the  ProgMan  FilelRun  menu.  You  must  first  install  the  BDE  before  you  can  run 
MARC  ES !  Once  the  program  is  running,  click  on  the  Help  menu  for  more  information. 
You  can  also  open  the  Help  file  independently  of  the  program.  You  should  find  this  file 
as  C:\MARC\DOC\MARCES.HLP.  To  open  the  file,  use  Windows  File  Manager  and 
double  click  on  the  MARCES.HLP  file. 

Troubleshooting.  If  you  experience  problems  installing  or  running  MARC  ES  or  any  of 
its  components,  here  are  some  hints  that  may  help  you  get  the  software  up  and  running 
correctly. 
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Check  the  BDE  configuration.  The  BDE  does  not  have  to  be  configured  in  order  to  run 
MARC  ES,  but  in  some  circumstances,  if  you  are  experiencing  problems  starting  up 
MARC  ES  or  accessing  the  tables,  a  solution  might  be  to  configure  the  BDE: 

Ensure  the  BDE  is  correctly  configured  to  access  the  databases.  Run  the  BDECFG 
program  under  Windows  to  set  up  the  BDE.  You  should  find  this  file  as 
C:VIDAPI\BDECFG.EXE.  The  configuration  it  expects  to  edit  will  be  the  file 
C:\IDAPI\IDAPI.CFG. 


The  BDECFG  is  easy  to  use  and  comes  with  on-line  help.  The  key  aspects  of  the 
configuration  are: 


Drivers: 
Aliases: 
Alias  Name: 
Type: 

Path: 


Ensure  that  the  dBASE  driver  is  configured. 
There  should  be  an  alias  defined  as  follows: 

marc  (must  be  all  lowercase) 
STANDARD 
C:\MARC\DATA 


Check  the  MARC.INI  File.  MARC.INI  is  created  in  the  MARC  directory.  The  default 
location  will  be  C:\MARC\MARC.INI.  The  simplest  way  to  look  at  this  file  is  to  open  the 
File  Manager  or  Explorer  and  double  click  on  the  MARC  .INI  file.  This  should  open 
Notepad  under  Windows. 

*****  NOTE:  EXERCISE  EXTREME  CAUTION  WHEN  EDITING  MARC.INI  ***** 
This  is  an  important  configuration  file.  If  it  is  incorrectly  edited  you  may  not  be  able  to  run  MARC  ES.  We 
suggest  you  make  a  backup  copy  of  this  file  in  case  it  is  damaged.  Sometimes  MARC  ES  may  not  be  able 
to  find  tables  if  the  pathnames  are  incorrect.  Review  the  pathnames  for  data,  reports,  and  help  files.  This  is 
particularly  important  if  you  have  multiple  disk  drives  on  your  machine,  or  if  you  are  using  networked 
drives.  If  this  is  the  case  then  you  should  ensure  that  the  MARC  ES  program  and  data  are  all  installed  on  the 
same  drive.  When  the  program  starts  up  it  assumes  that  the  data,  report,  help,  and  other  directories  are  on 
the  same  drive.  Do  not  add  drivenames  to  the  paths  in  MARC.INI. 
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